This invention relates generally to data processing systems. More particularly, it relates to communications between objects in different address spaces.
Object oriented programming (OOP) has been touted as a promising new technology to speed the development of software by allowing more efficient reuse and customization of software modules called objects. Objects are units of software which encapsulate both data and methods, an organization which makes the software both easier to maintain and enhance. Despite its promise, object oriented technology is only starting to be utilized in major commercial software products.
Several obstacles confront the software developer in using OOP. The first obstacle is the plethora of object oriented languages and toolkits which embrace different incompatible models of what objects are and how they should behave. For example, "pure" object oriented languages such as Smalltalk operate smoothly so long as they are in the supplied runtime environment. When interacting with foreign environments, the objects are reduced to data structures which do not retain the advantages of encapsulation and reuse which objects offer. Hybrid languages such as C++ require less runtime support, but employ tight bindings between the objects and their clients which means that the client programs have to be recompiled even when relatively minor changes are made to the objects. In summary, objects developed in one language could rarely be used in another.
The System Object Model, "SOM", is an object oriented technology designed to unite various object oriented approaches. In SOM, the interfaces of the classes of objects, the methods they support, the return types, and so forth are specified in the Interface Definition Language. The actual implementation of the object class can be written in any language the developer prefers, even a procedural language such as C. Thus, the advantages of OOP can be extended to programmers of non-object oriented programming languages. SOM is described in greater detail in copending and commonly assigned application, Ser. No. 07/805,668 "Language Neutral Objects" filed May 4, 1992 to M. Conner et al. which is hereby incorporated by reference.
Various standards bodies exist which encourage compliance to certain standard architectures. One of these standards is the Common Object Request Broker Architecture (CORBA) promulgated by the Object Management Group (OMG) and X/Open. The Object Request Broker (ORB) described in the architecture is analogous to the Remote Procedure Call (RPC) familiar to those working in the UNIX environments. Like the RPC, an ORB is a mechanism which allows processes working in one address space to communicate with others in another address space. An ORB intercepts a call from an object in one address space, encapsulates it into a network protocol, decodes the call for the target object in another address space and returns the results back to the calling object. Object Request Broker is an a improvement upon the RPC as it is designed to provide the higher level of flexibility and power offered by object oriented programming.
Unfortunately, since CORBA specifies the ORB interface but little about how ORBs function, it is possible to write ORBs which are CORBA compliant, but do not communicate with each other. In fact, this is the rule rather than the exception. Of the five or six ORB implementations known to the applicants, none can handle objects native to another ORB. Nor can the ORBs communicate with one another.
The present invention provides a mechanism for interconnecting a theoretically unlimited number of Object Request Brokers with arbitrary implementations.